A Packet Data Network (PDN) Connection is defined in the Third Generation Partnership Project Technical Specification (3GPP TS) 23.401 version 13.5.0, chapter 3 as an “association between a UE represented by one IPv4 address and/or one IPv6 prefix and a PDN represented by an APN”. UE is short for User Equipment, IPv4 is short for Internet Protocol version 4, IPv6 is short for Internet Protocol version 6 and APN is short for Access Point Name. The PDN consists of one default Evolved Packet System (EPS) Bearer and zero or more dedicated EPS Bearers. One piece of UE can have a number of PDN Connections, and each PDN connection can have one or more EPS Bearers. Many GPRS Tunneling Protocol (GTP) control signaling messages therefore contain lists of one or more EPS bearers, where each EPS bearer is identified by an EPS bearer Identity (Id). GPRS is short for General Packet Radio Services. Thus, the EPS bearer is between the UE and the PDN, and is used to transport IP (v4 and/or v6) packets to and from the UE and PDN.
Some of these GTP control signaling messages contain a list of all EPS bearers for the same UE or PDN connection (depending on the granularity of the message), while other messages contain a list of a subset of all EPS bearers for the same UE or PDN connection. Of these messages, the Modify Bearer Request and the Modify Access Bearers Request messages are of special interest.
The Modify Bearer Request message is used in a number of procedures over GTP based interfaces, most notably mobility procedures (Tracking Area Update/Routing Area Update/Handover (TAU/RAU/Handover), and Service Request procedures. In these procedures the Mobility Management Entity/S4-Serving GPRS Support Node (MME/S4-SGSN) sends one or more Modify Bearer Request messages (one message per PDN connection) over the S11/S4 interface to the Serving Gateway (SGW), and in some cases the SGW forwards the Modify Bearer Request messages over the S5/S8 interface to the Packet data network Gateway(s) (PDN GW, PGW(s)).
In cases when the UE has more than one PDN Connection and the procedure does not require signaling over the S5/S8 interface, the MME may, instead of sending one Modify Bearer Request message per PDN Connection for the same piece of UE, send one single Modify Access Bearers Request message with basically the same information as in the Modify Bearer Request messages the MME would have to send otherwise. The Modify Access Bearers Request message is only used on the S11 interface between the MME and the SGW.
The procedures that involve the Modify Bearer Request and Modify Access Bearers Request are described in 3GPP TS 23.401, with protocol details in 3GPP TS 29.274. The Modify Bearer Request message and the Modify Access Bearers Request message should contain a list of all EPS bearers for the same UE or PDN connection (depending on the granularity of the message):                The Modify Bearer Request message “shall contain all the bearers belonging to the given PDN connection” (3GPP TS 29.274, version 13.4.0, chapter 7.2.7).        The Modify Access Bearers Request message “shall contain all the bearers of all the existing PDN connections of the UE” (3GPP TS 29.274, version 13.4.0, chapter 7.2.24)        
To maintain information consistency between nodes, a receiver of a GTP control signaling message with a list of bearers needs to check that all the bearers in the received message are recognized by the receiving node. There should be no unknown bearers in the message. For messages that contain a list of a subset of all EPS bearers for the same UE or PDN connection (depending on the granularity of the message), checking that there are no unknown bearers in the message is enough. For messages that contain a list of all EPS bearers for the same UE or PDN connection (depending on the granularity of the message), the receiving node needs to check that there are no unknown bearers in the message. The receiving node also needs to check that all the EPS bearers for the same UE or PDN connection that exist in the receiving node are included in the received message. There should be no missing bearers.
This means that for messages that contain a list of all EPS bearers for the same UE or PDN connection (depending on the granularity of the message) there should be a one-to-one correspondence between the bearers in the message and the bearers in the receiving node.
If there is a mismatch between the list of bearers in the received (Modify Bearer Request or Modify Access Bearers Request) message and the bearers that are established in the receiving node, the receiving node needs to act in one way or another, in order to resolve the bearer mismatch.                When there is no bearer mismatch, the message should be accepted by the receiving node (unless there is some other problem with the message). The corresponding response message sent from the receiving node to the sending node includes a Cause information element with the Cause value set to “Request accepted”.        When all bearers are unknown by the receiving node, the message should be rejected by the receiving node with the Cause value set to “Context Not Found”. Note that the 3GPP standard also gives directives on when the message should be addressed to the peer node's (non-zero) Tunnel endpoint identifier (TEID) or to the generic TEID=0.        When there are one or more known bearers and one or more unknown bearers, the receiving node should “partially accept” the message (unless there is some other problem with the message). In the response, the main Cause value (the Cause information element on message level) should be set to “Request accepted partially”, and for each Bearer Context in the response message the corresponding bearer Cause value should be set to either “Request accepted” or “Context Not Found”, depending on whether the bearer is recognized by the receiving node or not.        
Before describing an example of a bearer mismatch, a known communication system 100 with a non-roaming architecture for Third Generation Partnership Project (3GPP) access will be described with reference to FIG. 1.
FIG. 1 shows a UE 101 which is served by a Radio Access Network (RAN) node (not shown in FIG. 1). The RAN node is comprised in a RAN, and the RAN is represented by Evolved-Universal Terrestrial Radio Access Network (E-UTRAN) 103 in FIG. 1. The RAN node may be for example a base station (in the GSM EDGE Radio Access Network (GERAN) 122), a NodeB (in the Universal Terrestrial Radio Access Network (UTRAN) 125), an evolved NodeB (eNode B, eNB) (in the E-UTRAN 103), Radio Network Controller (RNC) (in the UTRAN 125) or any other element capable to communicate with the UE 101. The reference point between the UE 101 and the E-UTRAN 103 may be referred to as Long Term Evolution-Uu (LTE-Uu). GSM is short for Global System for Mobile Communications and EDGE is short for Enhanced Data Rates for GSM Evolution.
The UE 101 may be a device by which a subscriber may access services offered by an operator's network and services outside operator's network to which the operators radio access network and core network provide access, e.g. access to the Internet. The UE 101 may be any device, mobile or stationary, enabled to communicate in the communications network, for instance but not limited to e.g. user equipment, mobile phone, smart phone, sensors, meters, vehicles, household appliances, medical appliances, media players, cameras, Machine to Machine (M2M) device, Device to Device (D2D) device, Internet of Things (IoT) device or any type of consumer electronic, for instance but not limited to television, radio, lighting arrangements, tablet computer, laptop or Personal Computer (PC). The UE 101 may be portable, pocket storable, hand held, computer comprised, or vehicle mounted devices, enabled to communicate voice and/or data, via the radio access network, with another entity, such as another UE or a server.
A MME 105 may be connected to the E-UTRAN 101 via the reference point S1-MME. The MME 105 is an element having functions such as e.g. Non-Access Stratum (NAS) signalling, Inter Core Network (CN) node signalling for mobility between 3GPP access networks, UE reachability, Tracking Area (TA) list management, PGW and SGW selection, MME selection for handover with MME change etc. S10 is the reference point between MMEs 105 for MME relocation and MME to MME information transfer.
Two gateways are seen in FIG. 1, i.e. the SGW 108 and the PGW 110. The SGW 108 and the PGW 110 may be implemented in one physical node or in separate physical nodes. The SGW 108 is the gateway which terminates the interface towards E-UTRAN 101. The reference point between the SGW 108 and the E-UTRAN 103 for the per bearer user plane tunneling and inter eNodeB path switching during handover may be referred to as S1-U. The SGW 108 routes and forwards user data packets, while also acting as the mobility anchor for the user plane during inter-eNodeB handovers and as the anchor for mobility between LTE and other 3GPP technologies (relaying the traffic between Second Generation/Third Generation (2G/3G) systems and the PGW 110) etc. S11 is the reference point between the SGW 108 and the MME 105.
The PGW 110 is the gateway which terminates the SGi interface towards the PDN. The PDN is illustrated in FIG. 1 by the Operator's IP Services (e.g. IMS, PSS etc.) 115. IMS is short for IP Multimedia Subsystem or IM Multimedia core network Subsystem and PSS is short for Packet Switched Streaming. If the UE 101 is accessing multiple PDNs, there may be more than one PGW 110 for that UE 101. Functions of the PGW 110 are e.g. providing connectivity from the UE 101 to external PDNs by being the point of exit and entry of traffic for the UE 101, performing policy enforcement, packet filtering for each user, charging support, lawful interception and packet screening etc. S5 is the reference point which provides user plane tunneling and tunnel management between the SGW 108 and the PGW 110.
The SGSN 118 is responsible for the delivery of data packets from and to the UE's 101 within its geographical service area. One of the SGSN's 118 functions is to provide signaling for mobility between 2G/3G and E-UTRAN 103 3GPP access networks. 2G/3G access network are exemplified with GERAN 122 and UTRAN 125 in FIG. 1. Some further functions of the SGSN 118 are to handle packet routing and transfer, mobility management (attach/detach and location management), logical link management, and authentication and charging functions etc. S3 is the interface between the SGSN 118 and the MME 105. S4 is a reference point between the SGSN 118 and the SGW 108. S12 is the reference point between the SGW 108 and the UTRAN 125. In some embodiments, the SGSN 118 and the MME 105 are co-located in one node. In this text, the term MME/SGSN will refer to any one of a standalone MME 105 or a standalone SGSN 108 or a combined MME 105 and SGSN 118 node. The SGSN 118 may also be referred to as a S4-SGSN. In the following, when the term MME is used, it refers to any of the standalone MME, a combined MME/SGSN or a combined MME/S4-SGSN. The term MME is used for the sake of simplicity.
The Home Subscriber Server (HSS) 128 is a subscriber server node similar to the GSM Home Location Register (HLR) and Authentication Centre (AuC). The HSS 128 comprises subscriber-related information (subscriber profiles), performs authentication and authorization of the user, and may provide information about the subscriber's location and IP information. The reference point S6a enables transfer of subscription and authentication data for authenticating/authorizing user access to the evolved system between the MME 105 and the HSS 128.
The Policy and Charging Rules Function (PCRF) 130 is a policy and charging control element. The PCRF 130 encompasses policy control decision and flow based charging control functionalities, it provides network control regarding the service data flow detection, gating, Quality of Service (QoS) and flow based charging etc. The PCRF 130 may be described as a functional entity which may be a standalone node or a function implemented in another node. The reference point Gx provides transfer of (QoS) policy and charging rules from the PCRF 130 to a Policy and Charging Enforcement Function (PCEF) in the PGW 110.
Rx is the reference point which resides between the PCRF 130 and the Operator's IP Services 118. The Rx reference point is used to exchange application level session information between the PCRF 130 and the Application Function (AF) (not shown).
In some embodiments, a communications system may be divided into a RAN and a CN. Thus, the UE 101 reaches the CN using a suitable access technology, for example the E-UTRAN 103 as exemplified in FIG. 1. Note that FIG. 1 uses E-UTRAN 103 as an example, and that the UE 101 may reach the CN using any other suitable access technology, both 3GPP technologies and non-3GPP technologies.
The RAN may be represented by e.g. the E-UTRAN 103 and may comprise a RAN node such as e.g. the base station as described above. Using FIG. 1 as an example, the CN may comprise the MME 108, the SGW 108, the PGW 110, the SGSN 118, the HSS 127 and the PCRF 130. The RAN and the CN may each comprises additional entities not shown in FIG. 1. The CN may be a Packet Switched (PS) core network or a Circuit Switched (CS) core network. In other embodiments, the communications system 110 is not divided into a RAN and a CN. Instead, the communications system 100 may comprise a virtualized CN, and the control and user planes are split. Terms such as Software Defined Network (SDN), Network Functions Virtualization (NFV) and Network Virtualization (NV) may be used in a scenario when with the virtualized CN where the control and user planes are split. The user plane (sometimes known as the data plane, forwarding plane, carrier plane or bearer plane) carries the network user traffic and that the control plane carries signalling traffic. As the SDN decouples the user and control planes, it removes the control plane from network hardware and implements it in software instead, which enables programmatic access and, as a result, makes network administration much more flexible. The control plane signalling may be routed to the virtualized CN and the user plane signalling is bypassed the virtualized CN. A virtualized CN may comprise virtual network services enabled by a virtualized MMME (vMME), virtualized SGSN (vSGSN), virtualized PGW (vPGW), virtualized SGW (vSGW), virtualized Gateway GPRS Support Node (vGGSN), virtualized PCRF (vPCRF), virtualized Deep Packet Inspection (vDPI), vProbe, virtualized Evolved Packet Data Gateway (vePDG) and virtualized Trusted Wireless Local Area Network Access Gateway (vTWAG) etc.
It should be noted that the communication links in the communications systems seen in FIG. 1 may be of any suitable kind including either a wired or wireless link. The link may use any suitable protocol depending on type and level of layer (e.g. as indicated by the Open Systems Interconnection (OSI) model) as understood by the person skilled in the art.
Now returning to an example of a bearer mismatch, as mentioned before FIG. 1 was described. FIG. 2 is an example of such bearer mismatch as a result of a connectivity problem or a temporary overload. At the start of the method, the MME 105, the SGW 108 and the PGW 110 all have information about that the EPS bearers with EPS Bearer Identities (EBI) 5, 6 are created. This is indicated with EBI={5,6} in FIG. 2. The method in FIG. 2 comprises at least some of the following steps, which steps may be performed in any suitable order than described below:
Step 200
The PGW 110 may send a Credit Control Request (CCR) message to the PCRF 130. The sending of the CCR may be a result of a procedure initiated from the MME 105, e.g. a mobility procedure. The PCRF 130 may receive the CCR message from the PGW 110.
Step 201
The PGW 110 receives Policy and Charging Control (PCC) rules from the PCRF 130, indicating that one or more dedicated bearers should be deactivated. The PCC rules are comprised in a Re-Authorization-Request (RAR) message or a Credit Control Answer (CCA) message sent by the PCRF 130 to the PGW 110. The PCC rules are comprised in the RAR in the scenario where the PGW 110 sends the RAA message in step 202, i.e. a scenario where step 200 is not performed. The PCC rules are comprised in the CCA message in a scenario where the PGW 110 has sent a CCR message in step 200. The PGW 110 receives the RAR or CCA message from the PCRF 130.
The CCA is a response to the CCR in step 200.
A PCC rule has several purposes, for example to detect that a packet belongs to a service data flow, to identify the service data flow, to provide applicable charging parameters for a service data flow, to provide policy control for a service data flow etc.
Step 202
When the PGW 110 has received and executed the PCC rules received from the PCRF 130, the PGW 110 may send a Re-Auth Answer (RAA) message to the PCRF 130. The RAA message is a response to the RAR message in step 201.
The following Table 1 provides an overview of the two scenarios in steps 200-203, where the left column represents the scenario which is initiated by the PCRF 130 and the right column represents the scenario which is initiated by the PGW 110:
TABLE 1Scenario 1: Initiated by PCRF 130Scenario 2: Initiated by PGW 110Step 201: PCRF 130 sendsStep 200: PGW 110 sendsRAR to PGW 110CCR to PCRF 130Step 202: PGW 110 replies withStep 201: PCRF 130 repliesRAA to PCRF 130with CCA to PGW 110
The above alternative scenarios 1 and 2 are also illustrated in FIG. 1. Thus, the RAR and RAA is an alternative to the CCR and CCA.
The receipt of the PCC rules may trigger a create bearer request, a delete bearer request or an update bearer request procedure.
Step 203
In this example it is assumed that the PGW 110 sends a Delete Bearer Request message to the SGW 108 to delete a dedicated bearer. The dedicated bearer to be deleted is the one with EBI={6}, The SGW 108 receives the Delete Bearer Request message from the PGW 110, and the SGW 108 forwards the Delete Bearer Request message to the MME 105.
FIG. 2 illustrates an example where one dedicated bearer is to be deleted. However, in other examples, the Delete Bearer Request message may comprise a list of a plurality of dedicated bearers to be deleted.
Due to temporary connectivity problems between the SGW 108 and the MME 105 or due to a temporary overload in the MME 105, the message does not reach the MME 105. The SGW 108 does not get any response from MME 105 to the Delete Bearer Request message (indicated with an “x” in FIG. 2), e.g. due to temporary connectivity problems between the SGW 108 and the MME 105. After a number seconds (the number of seconds may be referred to as a T3-RESPONSE seconds), the SGW 108 makes a new attempt to send the same message to the MME 105. The T3-RESPONSE seconds may be described as the time that the SGW 108 waits before resending the message and T3 may be described as a retry timer which is started when the Delete Bearer Request message has been sent. The number of attempts of resending of the message depends on the parameter N3-REQUESTS. The N3-REQUEST is a retry counter. 3GPP TS 29.274, V13.4.0 (2015-12), chapter 7.6 defines the T3-RESPONSE and N3-REQUEST as follows: “A timer, denoted T3-RESPONSE, shall be started when a signaling message (for which a reply is expected) is sent. A signaling message or the triggered message has probably been lost if a reply has not been received before the T3-RESPONSE timer expires. Once the T3-RESPONSE timer expires, the message corresponding to the T3-RESPONSE timer is then retransmitted if the total number of retry attempts is less than N3 REQUESTS times. [ . . . ]”
Step 204
The SGW 108 gives up in waiting for a response, and sends a Delete Bearer Response message to the PGW 110, with a Cause set to “Remote peer not responding”, where the remote peer is the MME 105. The SGW 108 and the PGW 110 deletes the bearer(s), as requested in step 203. After that the bearer still exists in the MME 105, while it is removed from SGW 108 and PGW 110. So since the PGW 110 does not receive any response, and after having exhausted all retransmission attempts the PGW 110 deletes the bearer anyway.
After the deletion of the bearer with EBI={6}, the SGW 108 and the PGW 110 has information about that the EBI={5} is the one which is created. The MME 105 still has information about EBI={5,6}.
Step 205
Later, when the connectivity is restored, or when the MME 105 has recovered from a temporary overload situation, the MME 105 sends a Modify Bearer Request message or a Modify Access Bearers Request message to the SGW 108 for the EBI={5,6}. The SGW 108 receives the Modify Bearer Request message from the MME 105. The SGW 108 detects a “Bearer mismatch”, i.e. the bearer 6 in the EBI={5,6} which is associated with the Modify Bearer Request message has been deleted as a result of step 204.
Problems with Existing Solutions
Problem #1: Missing Bearers
As described above, the standard provides a mechanism for handling unknown bearers in a GTP message. The mechanism is described above.
The standard does not state explicitly how missing bearers should be handled. Different interpretations are possible. One possibility for the receiving node is to accept the message and to locally delete any bearers that are not included in the received message. Another possibility is to reject the entire message, for example with a Cause value set to “Mandatory IE missing” or “Conditional IE missing”, and with the Offending Information Element (IE) set to “Bearer Context” to indicate that some bearer context is missing in the request message.
The probable result of rejecting the message is that the MME 105 will delete the PDN Connection and send a Delete Session Request message. Experience from live networks has shown that deleting PDN Connections in cases like this can have unwanted negative effects on end-user services, especially for time-critical services such as Voice over Long Term Evolution (VoLTE) and IMS emergency calls.
Problem #2: Racing Conditions
The 3GPP standard gives no advice on how to handle procedures that are executed more or less at the same time. The standard seems to have been written from the assumption that procedures are executed in isolation and that there is no need to consider effects of one procedure on another. This is the most severe problem with the existing solution.
The rule mentioned earlier, that for messages that contain a list of all EPS bearers for the same UE 101 or PDN connection (depending on the granularity of the message) there should be a one-to-one correspondence between the bearers in the message and the bearers in the receiving node, works only for the static case when bearers have been established at an earlier stage. The rule does not work while bearers are being created. The rule does not take into consideration that it takes some time to create a bearer across the involved nodes in the network, and that during that time different nodes will have a different number of bearers established.
The Modify Bearer Request message, as well as the Modify Access Bearers Request message contains bearers that exist in the MME 105 at the moment the message is sent from the MME 105. This is exemplified in FIG. 3 and FIG. 4.
FIG. 3 illustrates an example of a Procedure Using Modify Bearer Request. Optional steps are indicated with dotted arrows in FIG. 3. At the start of the method, the MME 105, the SGW 108 and the PGW 110 all have information about that the EPS bearers with EBI={5, 6} are created. This is indicated with EBI={5,6} in FIG. 3. The procedure in FIG. 3 comprises at least some of the following steps, which steps may be performed in any suitable order than described below:
Step 301
The MME 105 sends a Modify Bearer Request message to the SGW 108. The EPS Bearer Id of each bearer within the same PDN connection as known by the MME 105 is included in the message. The Modify Bearer Request message is for the bearer with EBI={5,6}, i.e. the Modify Bearer Request message comprises ID information which indicates the identities of the bearer to be modified, i.e. 5 and 6.
Under certain circumstances (defined in 3GPP TS 23.401), the SGW 108 may forward the Modify Bearer Request message to the PGW 110. The PGW 110 receives the forwarded Modify Bearer Request message from the SGW 108.
Step 302
The PGW 110 may interact with the PCRF 130 and by that the PGW 110 may send a CCR message to the PCRF 130. The PCRF 130 may receive the CCR message from the PGW 110. This is an optional step.
Step 303
The PCRF 130 may send a CCA message to the PGW 110. The PGW 110 may receive the CCA message from the PCRF 130. This is an optional step.
Step 304
The PGW 110 replies by sending a Modify Bearer Response message back to the SGW 108. The SGW 108 receives the Modify Bearer Response message from the SGW 108. SGW 108 replies by sending a Modify Bearer Response to the MME 105. The MME 105 receives the Modify Bearer Response message from the SGW 108.
FIG. 4 illustrates an example of a Procedure Using Modify Access Bearers Request. At the start of the method, the MME 105, the SGW 108 and the PGW 110 all have information about that the EPS bearers with EPS Bearer Identities (EBI) 5, 6 are created. This is indicated with EBI={5,6} in FIG. 4. The procedure in FIG. 4 comprises at least some of the following steps, which steps may be performed in any suitable order than described below:
Step 401
The MME 105 sends a Modify Access Bearers Request message to the SGW 108. The EPS Bearer Id of each bearer within all PDN connections for the same piece of UE 101 as known by the MME 105 is included in the message. The SGW 108 receives the Modify Access Bearers Request message from the MME 105. The Modify Access Bearers Request message comprises the identities of the bearers to be modified, i.e. bearers 5 and 6, EBI={5,6}.
Step 402
The SGW 108 replies with a Modify Access Bearers Response message to the MME 105. The MME 105 receives the Modify Access Bearers Response message from the SGW 108.
The PGW 110 is not involved in the procedure in FIG. 4.
A Default Bearer Activation procedure is exemplified in FIG. 5. The procedure in FIG. 5 comprises at least some of the following steps, which steps may be performed in any suitable order than described below:
Step 501
The UE 101 requests the MME 105 to establish a PDN Connection. The MME 105 sends a Create Session Request message to the SGW 108. The message includes the UE's International Mobile Subscriber Identity (IMSI), the APN to which the UE 101 wishes to be connected, and the EPS Bearer Id for the Default Bearer to be created. As an example, the EBI may be EBI={5}. Note that the MME 105 may choose any EBI in the interval 5 to 15 that is not already used by the UE 101. EBI={0} is used as a place-holder (in a Create Bearer Request message) for a bearer that has not yet been created. EBIs 1 to 4 are reserved.
The SGW 108 receives the Create Session Request message from the MME 105. The SGW 108 forwards the Create Session Request message to the PGW 110. The PGW 110 receives the forwarded Create Session Request message from the SGW 108.
Step 502
PGW 110 signals with PCRF 130 (and a number of other external systems, not shown in FIG. 5). This involves that the PGW 110 sends a CCR message to the PCRF 130, that the PCRF 130 receives the CCR message from the PGW 110, that the PCRF sends a CCA message to the PGW 110 and that the PGW 110 receives the CCA message from the PCRF 130.
Step 503
The PGW 110 then replies to the SGW 108 by sending a Create Session Response message. The message includes an allocated IP address for the UE 101, i.e. a PDN Address Allocation etc. The SGW 108 receives the Create Session Response message from the PGW 110. The SGW 108 forwards the Create Session Response message to the MME 105. The MME 105 receives the Create Session Response message from the SGW 108.
Step 504
The MME 105 sends a Modify Bearer Request message to the SGW 108. The SGW 108 receives the Modify Bearer Request message from the MME 105. The Modify Bearer Request message comprises EBI={5}, eNodeB Fully Qualified-Tunnel Endpoint Identifier (F-TEID), etc.
Step 505
The SGW 108 sends a Modify Bearer Response message to the MME 105. The MME 105 receives the Modify Bearer Response message from the SGW 108.
In a Dedicated Bearer Activation procedure, the new bearer(s) are created in one node at a time. More importantly: the bearers are given EPS Bearer Ids in one node at a time. A new bearer is given an EPS Bearer ID first in the MME 105, then in the SGW 108 and last in the PGW 110.
FIG. 6 illustrates an example of dedicated Bearer Activation. Optional steps are indicated with dotted arrows in FIG. 6. At the start of the method, the MME 105 the SGW 108 and the PGW 110 has information about the bearer with EBI={5}. EBI={5} may have been created as described in FIG. 6. The method in FIG. 6 comprises at least some of the following steps, which steps may be performed in any suitable order than described below:
Step 600
The PGW 110 may send a CCR message to the PCRF 130. The sending of the CCR may be a result of a procedure initiated from the MME 105, e.g. a mobility procedure. The PCRF 130 may receive the CCR message from the PGW 110.
Step 601
The PGW 110 receives PCC rules from the PCRF 130, indicating that one or more dedicated bearers should be created. The PCC rules are comprised in a RAR message or a CCA message sent by the PCRF 130 to the PGW 110. The PCC rules are comprised in the RAR in the scenario where the PGW 110 sends the RAA message in step 602, i.e. a scenario where step 600 is not performed. The PCC rules are comprised in the CCA message in a scenario where the PGW 110 has sent a CCR message in step 600. The PGW 110 receives the RAR or CCA message from the PCRF 130. The CCA is a response to the CCR in step 600.
Step 602
When the PGW 110 has received and executed the PCC rules received from the PCRF 130, the PGW 110 may send a RRA message to the PCRF 130. The RAA message is a response to the RAR message in step 601.
Thus, the RAR and RAA is an alternative to the CCR and CCA.
Table 1 described in relation to FIG. 2 provides an overview of the CCR, CCA, RAR and RAA messages, and is equally applicable to FIG. 6.
Step 603
The PGW 110 sends a Create Bearer Request message to the SGW 108. The EPS Bearer Id for each bearer will be decided by the MME 105. Thus, the Create Bearer Request message comprises EBI={0}. The SGW 108 receives the Create Bearer Request message from the PGW 110. The SGW 108 forwards the Create Bearer Request message to the MME 105. The MME 105 receives the Create Bearer Request message from the SGW 108. As described earlier, one or more bearers may be created with the same Create Bearer Request/Response message, but only one bearer is illustrated herein as an example.
Step 604
The MME 105 allocates an EPS Bearer Id for each bearer (e.g. EBI={6}) and replies by sending a Create Bearer Response message with the new EPS Bearer Id(s) back to the SGW 108. The SGW 108 receives the Create Bearer Response message from the MME 105. The SGW 108 forwards the Create Bearer Response message to the PGW 110.
As a result of this, all nodes have information about EBI={5,6}. This means, for example, that if a Modify Bearer Request message or a Modify Access Bearers Request message, which is supposed to contain a list of “all” EPS Bearers, is sent from an MME 105 in which a bearer has just been created and given an EPS Bearer Id, arrives at the receiving node (SGW 108 or PGW 110) before the same bearer has been created and given an EPS Bearer Id there, the receiving node will detect that the message contains an “unknown” bearer. If the receiving node rejects this bearer, the result is that the newly created bearer is deleted before it is completely created in all nodes. There may be a permanent bearer mismatch, and the end-user service will in any case not be delivered as expected.
FIG. 7 illustrates an example of a bearer deactivation procedure. At the start of the method, the MME 105 the SGW 108 and the PGW 110 has information about the two bearers with EBI={5,6}. The method in FIG. 7 comprises at least some of the following steps, which steps may be performed in any suitable order than described below:
Step 700
The PGW 110 may send a CCR message to the PCRF 130. The sending of the CCR may be a result of a procedure initiated from the MME 105, e.g. a mobility procedure. The PCRF 130 may receive the CCR message from the PGW 110.
Step 701
The PGW 110 receives PCC rules from the PCRF 130, indicating that one or more dedicated bearers should be deactivated. This may involve that the PCRF 130 sends a RAR or CCA message to the PGW 110, that the PGW 110 receives the RAR or CCA message from the PCRF 130, that the PGW 110 may send a RAA message to the PCRF 130 and that the PCRF 130 may receive the RAA message from the PGW 110.
The PCC rules are comprised in the RAR in the scenario where the PGW 110 sends the RAA message in step 701, i.e. a scenario where step 700 is not performed. The PCC rules are comprised in the CCA message in a scenario where the PGW 110 has sent a CCR message in step 700. The CCA is a response to the CCR in step 700.
Step 702
When the PGW 110 has received and executed the PCC rules received from the PCRF 130, the PGW 110 may send a RRA message to the PCRF 130. The RAA message is a response to the RAR message.
Thus, the RAR and RAA is an alternative to the CCR and CCA.
Table 1 described in relation to FIG. 2 provides an overview of the CCR, CCA, RAR and RAA messages, and is equally applicable to FIG. 7.
Step 703
The PGW 110 sends a Delete Bearer Request message to the SGW 108. The Delete Bearer Request message comprises information which indicates that it is the bearer with EBI={6} that should be deleted. The SGW 108 receives the Delete Bearer Request message from the PGW 110. The SGW 108 forwards the Delete Bearer Request message to the MME 105. The MME 105 receives the forwarded Delete Bearer Request message from the SGW 108. Deletion of a bearer may also be referred to as a deactivation of a bearer.
Step 704
The MME 105 deactivates the bearer(s) towards the eNodeB and replies by sending a Delete Bearer Response message back to the SGW 108. The SGW 108 receives the Delete Bearer Response message from the MME 105. The SGW 108 forwards the Delete Bearer Response message to the PGW 110. The PGW 110 receives the Delete Bearer Response message from the SGW 108.
The bearers are deleted in one node at a time (and not all nodes at the same time). It is when a node receives the Delete Bearer Response message that it should actually delete the bearer(s). It is because the bearers are deleted in one node at a time there can be bearer mismatches in signal racing conditions. In this sense the bearer deactivation procedures “mirrors” the bearer activation procedure.
After step 704, the nodes MME 105, the SGW 108 and the PGW 110 all have information about that it is only the bearer with EBI={5} that is activated, i.e. EBI={6} is deleted/deactivated.
In a racing condition, there is a risk that two peer nodes do not have exactly the same bearers at the same time.
A Permanent Bearer Mismatch can be caused by, for example                In the scenario described above with reference to FIG. 2.        An internal error forces a node to delete a bearer.        
A Temporary Bearer Mismatch can occur as a result of a signaling racing condition, for example:                The PGW 110 sends a Create Bearer Request message, and the MME 105 sends a Modify Bearer Request or Modify Access Bearers Request message. When the MME 105 also responds to the Create Bearer Request, there is a risk for a racing condition between the Create Bearer Response message and the Modify Bearer Request message, either on the S11/S4 interface between the MME 105 and the SGW 108, or on the S5/S8 interface between the SGW 108 and the PGW 110.        
This scenario has the following variations:                Modify Bearer Request arrives either before or after Create Bearer Response.        Modify Bearer Request either includes or does not include the newly created dedicated bearer(s).        
These variations combined result in four different cases which may occur in the PGW 110 or the SGW 108:
Case 1:                Modify Bearer Request arrives before Create Bearer Response.        Modify Bearer Request does not include the newly created dedicated bearer(s).        From the receiving node's point of view there is no problem.        
FIG. 8 illustrates an example of the Racing Condition: Create Bearer Response and Modify Bearer Request for case 1. There is a racing condition over two interfaces so that both SGW 108 and the PGW 110 must handle racing and bearer mismatch. The Create Bearer Response is also illustrated in FIG. 13 which will be described below.
A precondition for the method in FIG. 8 is that the Modify Bearer Request or Modify Access Bearers Request is sent from the MME 105 while a Bearer Activation procedure is triggered from the PGW 110.
Normal Case A:                Modify Bearer Request arrives before Create Bearer Response.        Modify Bearer Request does not include the newly created dedicated bearer(s).        
At the receiving node (SGW 108, MME 105)                No problem.        
Note that the situation may occur for the signaling over the S11/S4 interface between the MME/S4-SGSN 105 and the SGW 108, and also in the PGW 110 for signaling over S5/S8, S2a and over S2b.
At the start of the method in FIG. 8, the MME 105, the SGW 108 and the PGW 110 has information about that bearer with EBI={5} is activated. The method in FIG. 8 comprises at least some of the following steps, which steps may be performed in any suitable order than described below:
Step 800
The PGW 110 may send a CCR message to the PCRF 130. The sending of the CCR may be a result of a procedure initiated from the MME 105, e.g. a mobility procedure. The PCRF 130 may receive the CCR message from the PGW 110.
Step 801
The PGW 110 receives PCC rules from the PCRF 130, indicating that one or more dedicated bearers should be created. The PCC rules are comprised in a RAR message or a CCA message sent by the PCRF 130 to the PGW 110. The PCC rules are comprised in the RAR in the scenario where the PGW 110 sends the RAA message in step 802, i.e. a scenario where step 800 is not performed. The PCC rules are comprised in the CCA message in a scenario where the PGW 110 has sent a CCR message in step 800. The PGW 110 receives the RAR or CCA message from the PCRF 130.
The PGW 110 receives the RAR or CCA message from the PCRF 130. The CCA is a response to the CCR in step 600.
Step 802
When the PGW 110 has received and executed the PCC rules received from the PCRF 130, the PGW 110 may send a RRA message to the PCRF 130. The RAA message is a response to the RAR message in step 801.
Thus, the RAR and RAA is an alternative to the CCR and CCA.
Table 1 described in relation to FIG. 2 provides an overview of the CCR, CCA, RAR and RAA messages, and is equally applicable to FIG. 8.
Step 803
The PGW 110 sends a Create Bearer Request message to the SGW 108. The SGW 108 receives the Create Bearer Request message from the PGW 110. The SGW 108 forwards the Create Bearer Request message to the MME 105. The MME 105 receives the Create Bearer Request message from the SGW 108.
The Create Bearer Request message may comprise information which indicates that EBI={0} is the bearer which should be created.
Step 804
The MME 105 sends a Modify Bearer Request message to the SGW 108. The SGW 108 receives the Modify Bearer Request message from the MME 105. The SGW 108 sends the Modify Bearer Request message to the PGW 110. The PGW 110 receives the Modify Bearer Request message from the SGW 108.
In one example, the Modify Bearer Request message comprises information which indicates that the bearer with EBI={5} is the one which should be modified (this is referred to as Alt. 1 in FIG. 8). When the SGW 108 receives the Modify Bearer Request message, it expects EBI={5} (referred to as Alt. A in FIG. 8). When the PGW 110 receives the Modify Bearer Request message, the PGW 110 expects EBI={5} (referred to as and Alt. A in FIG. 8).
In a second example alternative, the Modify Bearer Request message comprises information which indicates that the bearer with EBI={5,6} are the ones to be modified (this is referred to as Alt. 2 in FIG. 8). When the SGW 108 receives the Modify Bearer Request message, it expects EBI={5,6} (this is referred to as Alt. B in FIG. 8). When the PGW 110 receives the Modify Bearer Request message, it expects EBI={5,6} (this is referred to as Alt. B in FIG. 8).
Step 805
The SGW 108 sends a Create Bearer Response message to the PGW 110. The PGW 110 receives the Create Bearer Response message from the SGW 108.
The Create Bearer Response message comprises information which indicates that the bearer with EBI={6} is the one which should be created.
The cloud with the dotted lines in FIG. 8 indicates that messages sent over a certain interface may be sent in one order and be received at the other node in another order. In FIG. 8, the MME 105 may have sent the Create Bearer Response message to the SGW 108 before the Modify Bearer Request, but the Modify Bearer Request messages may (due to racing) reach the SGW 108 before the Create Bearer Response message reaches the SGW 108. The SGW 108 may send the Create Bearer Response message before the Modify Bearer Request message, but the Modify Bearer Request message may (due to racing) reach the PGW 110 before the Create Bearer Response message does. Such racing conditions may cause a bearer mismatch between the bearer(s) indicated in a message received by a gateway (e.g. EBI={5}) and the bearer(s) known by the gateway (e.g. EBI={5,6}), which bearers are associated with the same PDN connection and the same UE 101.
The SGW 108 may forward the messages to the PGW 110 in the same order as the SGW 108 receives them from the MME 105.
Then there can be a new racing over the S5/S8 interface.
As seen in FIG. 8, both the SGW 108 and the PGW 110 must handle racing and bearer mismatch.
Summarized, FIG. 8 shows that messages sent over a certain interface may be sent in one order and be received at the other node in another order. The MME 105 may send “message A” before “message B”, but “message B” may (due to racing) reach the SGW 108 before “message A” does. The SGW 108 may send “message A” before “message B”, but “message B” may (due to racing) reach the PGW 110 before “message A” does. Thus it is possible to have a racing condition over both S11/S4 and S5/S8 interfaces.
Case 2:                Create Bearer Response arrives before Modify Bearer Request.        Modify Bearer Request includes the newly created dedicated bearer(s).        From the receiving node's point of view there is no problem.        
FIG. 9 illustrates an example of a Racing Condition for a Create Bearer Response and Modify Bearer Request for case 2. Case 2 is also illustrated in FIGS. 13 and 14 which will be described below.
A precondition for FIG. 9 is that a Modify Bearer Request or Modify Access Bearers Request is sent from MME/S4-SGSN 105 while a Bearer Activation procedure is triggered from the PGW 110.
Normal case B:                Create Bearer Response arrives before Modify Bearer Request.        Modify Bearer Request includes the newly created dedicated bearer(s).        
At the receiving node (SGW 108, MME 105105):                No problem.        
Note that the situation may occur for the signaling over the S11/S4 interface between the MME/S4-SGSN 105 and the SGW 108, and also in the PGW 110 for signaling over S5/S8, S2a and over S2b.
At the start of the method in FIG. 9, the MME 105, the SGW 108 and the PGW 110 has information about that bearer with EBI={5} is activated. The method in FIG. 9 comprises at least some of the following steps, which steps may be performed in any suitable order than described below:
Step 900
The PGW 110 may send a CCR message to the PCRF 130. The sending of the CCR may be a result of a procedure initiated from the MME 105, e.g. a mobility procedure. The PCRF 130 may receive the CCR message from the PGW 110.
Step 901
The PGW 110 receives PCC rules from the PCRF 130, indicating that one or more dedicated bearers should be created.
The PCC rules are comprised in the RAR in the scenario where the PGW 110 sends the RAA message in step 901, i.e. a scenario where step 900 is not performed. The PCC rules are comprised in the CCA message in a scenario where the PGW 110 has sent a CCR message in step 900.
The PGW 110 receives the RAR or CCA message from the PCRF 130. The CCA is a response to the CCR in step 900.
When the PGW 110 has received and executed the PCC rules received from the PCRF 130 and when it has received the RAR message, the PGW 110 may send a RRA message to the PCRF 130. The RRA message is a response to the RAR message in step 900.
Thus, the RAR and RAA is an alternative to the CCR and CCA.
Table 1 described in relation to FIG. 2 provides an overview of the CCR, CCA, RAR and RAA messages, and is equally applicable to FIG. 9.
Step 902
The PGW 110 sends a Create Bearer Request message to the SGW 108. The SGW 108 receives the Create Bearer Request message from the PGW 110. The SGW 108 forwards the Create Bearer Request message to the MME 105. The MME 105 receives the Create Bearer Request message from the SGW 108.
Step 903
The SGW 108 sends a Create Bearer Response message to the PGW 110. The Create Bearer Response message comprises information which indicates that the bearer with EBI={6} has been created.
Step 904
The SGW 108 sends a Modify Bearer Request message to the PGW 110. The PGW 110 receives the Modify Bearer Request message from the SGW 108. The Modify Bearer Request message comprises information which indicates that the bearers with EBI={5,6} are the ones that should be modified. The PGW 110 expects EBI={5,6} to be in the message from the SGW 108.
Similar to FIG. 8, the cloud and the crossed dotted lines within the cloud indicates that the MME 105 may send the message in a different order than they arrive at the PGW 110 which may cause a racing condition. Such racing conditions may cause a bearer mismatch between the bearer(s) indicated in a message received by a gateway (e.g. EBI={6}) and the bearer(s) known by the gateway (e.g. EBI={5,6}), which bearers are associated with the same PDN connection and the same UE 101.
Case 3:                Modify Bearer Request arrives before Create Bearer Response.        Modify Bearer Request includes the newly created dedicated bearer(s).        From the receiving node's point of view the received Modify Bearer Request message contains one or more unknown bearers.        The Create Bearer Response message contains the bearers that were “unknown” in the Modify Bearer Request message.        
FIG. 10 illustrates an example of the Racing Condition with a Create Bearer Response and Modify Bearer Request for case 3. Case 3 is also illustrated in FIGS. 13 and 14 which will be described below.
A precondition for FIG. 10 is that the Modify Bearer Request or Modify Access Bearers Request is sent from MME/S4-SGSN 105 while a Bearer Activation procedure is triggered from the PGW 110.
Exceptional case A:                Modify Bearer Request arrives before Create Bearer Response.        Modify Bearer Request includes the newly created dedicated bearer(s).        
At the receiving node (SGW 108, MME 105):                From the receiving node's point of view the received Modify Bearer Request message contains one or more unknown bearers.        
Note that the situation may occur for the signaling over the S11/S4 interface between the MME/S4-SGSN 105 and the SGW 108, and also in the PGW 110 for signaling over S5/S8, S2a and over S2b.
At the start of the method in FIG. 10, the MME 105, the SGW 108 and the PGW 110 has information about that bearer with EBI={5} is activated. The method in FIG. 10 comprises at least some of the following steps, which steps may be performed in any suitable order than described below:
Step 1000
The PGW 110 may send a CCR message to the PCRF 130. The sending of the CCR may be a result of a procedure initiated from the MME 105, e.g. a mobility procedure. The PCRF 130 may receive the CCR message from the PGW 110.
Step 1001
The PGW 110 receives PCC rules from the PCRF 130, indicating that one or more dedicated bearers should be created. The PCC rules are comprised in the RAR in the scenario where the PGW 110 sends the RAA message, i.e. a scenario where step 1000 is not performed. The PCC rules are comprised in the CCA message in a scenario where the PGW 110 has sent a CCR message in step 1000. The PGW 110 receives the RAR or CCA message from the PCRF 130. The CCA is a response to the CCR in step 1000.
The PGW 110 receives the RAR or CCA message from the PCRF 130. When the PGW 110 has received and executed the PCC rules received from the PCRF 130 and when the RAA message has been received by the PGW 110, the PGW 110 may send a RRA message to the PCRF 130. The RAA message is a response to the RAR message in step 1001.
Thus, the RAR and RAA is an alternative to the CCR and CCA.
Table 1 described in relation to FIG. 2 provides an overview of the CCR, CCA, RAR and RAA messages, and is equally applicable to FIG. 10.
Step 1002
The PGW 110 sends a Create Bearer Request message to the SGW 108. The SGW 108 receives the Create Bearer Request message from the PGW 110. The SGW 108 forwards the Create Bearer Request message to the MME 105. The MME 105 receives the Create Bearer Request message from the SGW 108.
Step 1003
The SGW 108 sends a Modify Bearer Request message to the PGW 110. The PGW 110 receives the Modify Bearer Request message from the SGW 108. The Modify Bearer Request message comprises information which indicates that the bearers with EBI={5,6} should be modified. As mentioned above, the PGW 110 only has information about EBI={5} as the activated bearer, and therefore only expects EBI={5} in the message from the SGW 108.
Step 1004
The SGW 108 sends a Create Bearer Response message to the PGW 110. The PGW 110 receives the Create Bearer Response message from the SGW 108. The Create Bearer Response message comprises information which indicates that the bearer with EBI={6} should be created.
As for the FIGS. 8 and 9, the cloud with the dotted crossed lines in FIG. 10 illustrates that the order in which the messages are sent from the MME 105 is not the same as the order in which the same messages are received by the PGW 110. In particular, the Create Bearer Response message is sent before the Modify Bearer Request message is sent from the MME 105, and the Modify Bearer Request message is received before the Create Bearer Response message at the PGW 110. As mentioned above, the PGW 110 only has information about EBI={5} as the activated bearer, and therefore only expects EBI={5} in the message from the SGW 108. So, when the Modify Bearer Request message indicates EBI={5,6}, there is a mismatch since EBI={6} is unknown to the PGW 110.
Case 4:                Create Bearer Response arrives before Modify Bearer Request.        Modify Bearer Request does not include the newly created dedicated bearer(s).        From the receiving node's point of view one or more bearers are missing in the received Modify Bearer Request message.        The Create Bearer Response message contains the bearers that were “missing” from the Modify Bearer Request message.        
FIG. 11 illustrates an example of the Racing Condition for the Create Bearer Response and Modify Bearer Request according to case 4. Case 4 is also illustrated in FIGS. 13 and 14 which will be described below.
A precondition for FIG. 11 is that the Modify Bearer Request or Modify Access Bearers Request is sent from MME/S4-SGSN 105 while a Bearer Activation procedure is triggered from PGW.
Exceptional Case B:                Create Bearer Response arrives before Modify Bearer Request.        Modify Bearer Request does not include the newly created dedicated bearer(s).        
At the receiving node (SGW 108, MME 105105):                From the receiving node's point of view one or more bearers are missing in the received Modify Bearer Request message.        
Note that the situation may occur for the signaling over the S11/S4 interface between the MME/S4-SGSN 105 and the SGW 108, and also in the PGW 110 for signaling over S5/S8, S2a and over S2b.
At the start of the method in FIG. 11, the MME 105, the SGW 108 and the PGW 110 has information about that bearer with EBI={5} is activated. The method in FIG. 11 comprises at least some of the following steps, which steps may be performed in any suitable order than described below:
Step 1100
The PGW 110 may send a CCR message to the PCRF 130. The sending of the CCR may be a result of a procedure initiated from the MME 105, e.g. a mobility procedure. The PCRF 130 may receive the CCR message from the PGW 110.
Step 1101
The PGW 110 receives PCC rules from the PCRF 130, indicating that one or more dedicated bearers should be created. The PCC rules are comprised in the RAR in the scenario where the PGW 110 sends the RAA message, i.e. a scenario where step 1100 is not performed. The PCC rules are comprised in the CCA message in a scenario where the PGW 110 has sent a CCR message in step 1100. The CCA is a response to the CCR in step 1100.
The PGW 110 receives the RAR or CCA message from the PCRF 130.
Step 1102
When the PGW 110 has received and executed the PCC rules received from the PCRF 130 and when the PGW 110 has received the RAR message, the PGW 110 may send a RRA message to the PCRF 130.
The RAA message is a response to the RAR message in step 1101.
Thus, the RAR and RAA is an alternative to the CCR and CCA.
Table 1 described in relation to FIG. 2 provides an overview of the CCR, CCA, RAR and RAA messages, and is equally applicable to FIG. 11.
Step 1103
The PGW 110 sends a Create Bearer Request message to the SGW 108. The SGW 108 receives the Create Bearer Request message from the PGW 110. The SGW 108 forwards the Create Bearer Request message to the MME 105. The MME 105 receives the Create Bearer Request message from the SGW 108.
Step 1104
The SGW 108 sends a Create Bearer Response message to the PGW 110. The PGW 110 receives the Create Bearer Response message from the SGW 108. The Create Bearer Response message comprises information which indicates that the bearer with EBI={6} should be created.
Step 1105
The SGW 108 sends a Modify Bearer Request message to the PGW 110. The PGW 110 receives the Modify Bearer Request message from the SGW 108. The Modify Bearer Request message comprises information which indicates that the bearer with EBI={5} should be modified. However, the PGW 110 expected the Modify Bearer Response message to indicate EBI={5,6} since they are the ones which are created. Such racing conditions cause a bearer mismatch between the bearer(s) indicated in a message received by PGW 110 (e.g. EBI={5}) and the bearer(s) known by the PGW 110 (e.g. EBI={5,6}), which bearers are associated with the same PDN connection and the same UE 101.
As for the FIGS. 8, 9 and 10, the cloud with the dotted crossed lines in FIG. 11 illustrates that the order in which the messages are sent from the MME 105 is not the same as the order in which the same messages are received by the PGW 110. In particular, the Modify Bearer Request message is sent before the Create Bearer Response message is sent from the MME 105, and the Create Bearer Response message is received before the Modify Bearer Request message at the PGW 110.
The racing conditions described so far all have in common that they involve Modify Bearer Request/Modify Access Bearers Request and Create Bearer Response. Situations in which this is likely to occur are when:                A mobility procedure (TAU/RAU/Handover) is initiated in parallel with a dedicated bearer activation procedure.        A UE initiated service request procedure is initiated in parallel with a dedicated bearer activation procedure.        A dedicated bearer activation procedure is initiated while there are no active S1-U tunnels between the SGW 108 and the eNodeB 103, or no active S4-U tunnels between the SGW 108 and the S4-SGSN 118, or no active S12-U tunnels between the SGW 108 and the RNC, which triggers a network triggered service request procedure.        A dedicated bearer activation procedure is initiated in combination with the default bearer activation at Attach and UE 101 requested PDN connectivity procedures.        During other procedures, e.g. E-UTRAN 103 initiated E-RAB modification procedure, HSS based P-CSCF Restoration procedure, Presence Area Reporting and so on, where the MME 105 initiates Modify Bearer Request in parallel with a dedicated bearer activation procedure initiated from the PGW 110.        
The above cases 1-4 describe a racing condition that involves the Create Bearer Request. Note that a racing condition may also occur for a Delete Bearer Request. The Delete Bearer Request is described in more detail with reference to case 5-8 in FIG. 14. The Create Bearer Request and the Delete Bearer Request have in common that the order in which the signals are received, as well as which bearers are expected by the receiving node bearers are the same, but the bearer mismatches are different (cf. FIGS. 13 and 14). The Create Bearer case 1 is similar to the Delete Bearer case 5. The Create Bearer case 2 is similar to the Delete Bearer case 6. The Create Bearer case 3 relates to an unknown bearer, but the Delete Bearer case 7 relates to a missing bearer. The Create Bearer case 4 relates to a missing bearer and the Delete Bearer case 8 relates to an unknown bearer. This is described in more detail with reference to FIGS. 13 and 14 below.
The fourth case listed above, “dedicated bearer activation procedure is initiated in combination with the default bearer activation at Attach and UE 101 requested PDN connectivity procedures”, is described in 3GPP TS 23.401 Annex F. It may be referred to as the “piggybacking scenario”, since it describes how Create Bearer Request can be piggybacked on a Create Session Response message, and Modify Bearer Request on a Create Bearer Response message. The standard does not state clearly whether the MME 105 should include the newly created bearer or not in the Modify Bearer Request. In the “piggybacking scenario” it may seem reasonable that the MME 105 would be aware of the newly created bearer at the time it sends the Modify Bearer Request. In the case piggybacking is not supported both possibilities (i.e. include or not include the newly created bearer) seems equally plausible. This racing condition is illustrated in FIG. 12. FIG. 12 illustrates an example of a Dedicated bearer activation in combination with the default bearer activation at Attach and UE requested PDN connectivity procedures.
The method in FIG. 12 comprises at least some of the following steps, which steps may be performed in any suitable order than described below:
Step 1201
The MME 105 sends a Create Session Request message to the SGW 108. The SGW 108 receives the Create Session Request message from the MME 105. The SGW 108 forwards the Create Session Request message to the PGW 110. The PGW 110 receives the Create Session Request message from the SGW 108. The Create Session Request message comprises information which indicates that the session for the bearer with EBI={5} should be created.
Step 1202
The PGW 110 receives PCC rules from the PCRF 130, indicating that one or more dedicated bearers should be created. The PGW 110 sends a CCR message to the PCRF 130. The PCC rules are comprised in a CCA message sent by the PCRF 130 to the PGW 110. The PGW 110 receives the CCA message from the PCRF 130.
Step 1203
The PGW 110 sends a Creates Session Response message to the SGW 108. The SGW 108 receives the Create Session Response message from the PGW 110. The SGW 108 sends the Create Session Response message to the MME 105. The MME 105 receives the Create Session Response message from the SGW 108. The Create Session Response message is a response to the Create Session Request message in step 1201.
Step 1204
The PGW 110 sends a Create Bearer Request message to the SGW 108. The SGW 108 receives the Create Bearer Request message from the PGW 110. The SGW 108 sends the Create Bearer Request message to the MME 105. The MME 105 receives the Create Bearer Request message from the SGW 108.
Step 1205
The SGW 108 may send a Modify Bearer Request message to the PGW 110. The PGW 110 may receive the Modify Bearer Request message from the SGW 110. The Modify Bearer Request message may comprise information which indicates that either the EBI={5} or EBI={5,6} should be modified.
Step 1206
The SGW 108 may send a Create Bearer Response message to the PGW 110. The PGW 110 may receive the Create Bearer Response message from the SGW 108. The Create Bearer Response comprises information which indicates that the bearer with EBI={6} should be created. The Create Bearer Response message is a response to the Create Bearer Request message in step 1204.
The cloud with the dotted crossed lines in FIG. 12 illustrates that the order in which the messages are sent from the MME 105 is not the same as the order in which the same messages are received by the PGW 110. In particular, the Create Bearer Response message is sent before the Modify Bearer Request message is sent from the MME 105, and the Modify Bearer Request message is received before the Create Bearer Response message at the PGW 110.
Step 1207
The PGW 110 may send a Modify Bearer Response message to the SGW 108. The SGW 108 may receive the Modify Bearer Response message from the PGW 110. The SGW 108 may send the Modify Bearer Response message to the MME 105. The MME 105 may receive the Modify Bearer Response message from the SGW 108.
FIG. 13 illustrates the four different cases 1-5 for a create bearer scenario in the SGW 108. A precondition for FIG. 13 is that the default bearer EBI={5} exists and that the SGW 108 has handled a Create Bearer Request message. Case 1-5 in FIG. 13 corresponds to cases 1-4 described above.
Case 1
In case 1, the SGW 108 first receives a Modify Bearer Request message with EBI={5} and the SGW 108 expects EBI={5}. The SGW 108 then concludes that the bearers match perfectly. The SGW 108 then receives a Create Bearer Response message with EBI={6}. The SGW 108 concludes with that the MME 105 has created a bearer with EBI={6}. In case 1, the Modify Bearer Request message is received before the Create Bearer Response message and there is no racing condition. Case 1 is also illustrated in FIG. 8.
Case 2
In case 2, the SGW 108 first receives a Create Bearer Response message with EBI={6}. The SGW 108 then concludes that the MME 105 has created the bearer with EBI={6}. The SGW 108 then receives a Modify Bearer Request message with EBI={5,6}, and the SGW 108 expects EBI={5,6}. Thus, the SGW 108 concludes with that the bearers match perfectly. In case 2, the Create Bearer Response message is received before the Modify Bearer Request message, and there is no racing condition. Case 2 is also illustrated in FIG. 9.
Case 3
In case 3, the SGW 108 first receives a Modify Bearer Request message with EBI={5,6} and the SGW 108 expects EBI={5}. The SGW 108 concludes that there is a bearer mismatch since EBI={6} is unknown. Case 3 is also illustrated in FIG. 10.
Unknown bearers are covered by the current standard. The SGW 108 should reply with (main) Cause set to “Request accepted partially”, and Cause in Bearer Contexts set to “Request accepted” (for EBI={5}), and “Context not found” (for EBI={6}). The most probable effect of that is that MME 105 will delete the newly created bearer(s) locally. When the Create Bearer Response arrives the new bearer will be established in SGW 108 but it is deleted in MME 105.
So for case 3, there is a racing condition since the MME 105 sends the Create Bearer Response message before the Modify Bearer Request, but messages arrive at the SGW 108 in opposite order.
Case 4
The SGW 108 first receives a Create Bearer Response message with EBI={6}. The SGW 108 concludes that the MME 105 has created a bearer with EBI={6}. Secondly, the SGW 108 receives a Modify Bearer Request message with EBI={5} and the SGW 108 expects EBI={5,6}. The SGW 108 concludes that there is a bearer mismatch since EBI={6} is missing. Case 4 is also illustrated in FIG. 11.
The current standard does not give explicit directives on how to handle messages with missing bearers. A possible interpretation of the standard is that the message should be rejected with Cause set to “Mandatory IE missing”. The most probable effect of that is that the MME will delete the entire PDN connection and send Delete Session Request.
There is racing condition in case 4 since the MME 105 sends the Modify Bearer Request message before the Create Bearer Response message, but messages arrive at the SGW 108 in opposite order.
FIG. 14 illustrates four different cases 5-8 for a delete bearer scenario in the SGW 108. A precondition for FIG. 14 is that the default bearer with EBI={5} and the dedicated bearer with EBI={6} exists, and that the SGW 108 has handled a Delete Bearer Request message for EBI={6}.
Case 5
In case 5, the SGW 108 first receives the Modify Bearer Request message with EBI={5,6} and the SGW 108 expects EBI={5,6}. The SGW 108 concludes that the bearers match perfectly. Then, the SGW 108 receives the Delete Bearer Response message and the SGW 108 concludes that the MME 105 has deleted the bearer with EBI={6}. The SGW 108 also deletes the bearer with EBI={6}, and forwards the Delete bearer Response message to the PGW 110. So in case 5, the Modify Bearer Request message is received before the Delete Bearer Response message and there is no racing condition. Case 5 in FIG. 14 is similar to case 1 illustrated in FIG. 9 except that FIG. 14 is for a Delete Bearer Response and FIG. 9 is for a Create Bearer Response message.
Case 6
In case 6, the SGW 108 first receives the Delete Bearer Response message with EBI={6}. The SGW 108 concludes that the MME 105 has deleted the bearer with EBI={6}. The SGW 108 also deletes the bearer with EBI={6}, and forwards the Delete Bearer Response message to the PGW 110. Secondly, the SGW 108 receives the Modify Bearer Request message with EBI={5} and the SGW expects EBI={5} in the message. The SGW 108 concludes that the bearers match perfectly. So in case 6, the Delete Bearer Response message is received before the Modify Bearer Request message and there is no racing condition. This corresponds to case 2 illustrated in FIG. 8.
Case 7
In case 7, the SGW 108 first receives the Modify Bearer Request message with EBI={5} and the SGW 108 expects EBI={5,6} in the message. The SGW 108 concludes that there is a bearer mismatch and that EBI={6} is missing.
The current standard does not give explicit directives on how to handle messages with missing bearers. A possible interpretation of the standard is that the message should be rejected with Cause set to “Mandatory IE missing”. The most probable effect of that is that the MME will delete the entire PDN connection and send Delete Session Request. Secondly, in case 7, the SGW 108 receives the Delete Bearer Response message with EBI={6}, and the SGW 108 concludes that the MME 105 has deleted the bearer with EBI={6}. The SGW 108 also deletes the barer with EBI={6}, and forwards the Delete Bearer Response message to the PGW 110.
Thus, in case 7 there is a racing condition since the MME 105 sends the Delete Bearer Response message before the Modify Bearer Request message, but the messages arrive at the SGW 108 in opposite order.
Case 7 in FIG. 14 is similar to case 3 illustrated in FIG. 10 except that FIG. 14 is for a Delete Bearer Response and FIG. 10 is for a Create Bearer Response message.
Case 8
In case 8, the SGW 108 first receives the Delete Bearer Response message with EBI={5} and the SGW 108 concludes that the MME 105 has deleted the bearer with EBI={6}. The SGW 108 also deletes the bearer with EBI={6}, and forwards the Delete Bearer Response message to the PGW 110. Secondly, the SGW 108 receives the Modify Bearer Request message with EBI={5,6} and the SGW 108 expects EBI={5,6} in the message. The SGW 108 then concludes with that there is a bearer mismatch and that EBI={6} is unknown.
As mentioned earlier, unknown bearers are covered by the current standard. The SGW 108 should reply with (main) Cause set to “Request accepted partially”, and Cause in Bearer Contexts set to “Request accepted” (for EBI=5), and “Context not found” (for EBI=6). In the “Delete scenario” this does not cause any problems.
In case 8, the MME 105 sends the Modify Bearer Request message before the Delete Bearer Response message, but the messages arrive at the SGW 108 in opposite order
Case 8 in FIG. 14 is similar to case 4 illustrated in FIG. 11 except that FIG. 14 is for a Delete Bearer Response and FIG. 11 is for a Create Bearer Response message.
The racing conditions described so far include Create Bearer Request/Response, and Modify Bearer Request or Modify Access Bearers Request. Similar racing conditions can occur with Delete Bearer Request/Response, and Modify Bearer Request or Modify Access Bearers Request.
The current standard covers Permanent Bearer Mismatch with Unknown Bearers well enough. The mechanism provides feedback to the originating node, which makes it possible for the originating node to deactivate the bearer(s) that were unknown to the receiving node.
The current standard does not cover Temporary Bearer Mismatch (in racing conditions). The current standard does not cover Missing Bearers well enough.
The current standard seems to have been written from the perspective that each procedure takes place in isolation, from the perspective that two procedures never take place at the same time, and that signaling racing conditions have no effect on the involved procedures.